Nautilus 1992 July/Nautilus-3-8/Nautilus-3-8.bin/Tools & Utilities/Techy Stuff/Doco ƒ/CSMP ƒ/CSMP-V1-090.TXT

Text File | 1992-06-30 | 42.3 KB | 1,104 lines

C.S.M.P. Digest             Fri, 22 May 92       Volume 1 : Issue 90

Today's Topics:

    Application Menu missing
    Using Fix2X and X2Fix
    Broken Sample Screen Saver?
    What is "Tuna Helper" INIT in my system?
    MPW's C preprocessor bug
    LaserPrep enforcer ??
    Finding the Event Queue, etc.
    Alternatives to fopen() in Think C?
    Apple Installer Scripts
    Too many files open?


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail]
Subject: Application Menu missing
Date: 15 Apr 92 12:20:23 GMT
Organization: Oxford University VAXcluster

Dear Think C 5 users,

Two problems:
(1)
I can't get the Application menu to appear when running my previously
Multifinder-compatible Think-C 4 program after switching to Think-C 5 and
System 7, either when running as a project or as a standalone application.
Any clues?

(2)
What's the definitive method for creating files with icons?  Is it possible to
prompt a user via SFPutFile and then CreateFile the file with the icon?  My
file doesn't seem to pick up the Creator info when I do this.

*** Please direct any replies to  [e-mail] and I will summarise
*** if it warrants. (ie "If I'm not >>Really<< stupid!!!)

Kevin Crawford
ICRF Cell Cycle Group
Oxford University
UK

+++++++++++++++++++++++++++

From: [e-mail]
Date: 21 Apr 92 14:38:19 GMT
Organization: Oxford University VAXcluster

Reposted due to lack of response:
 Dear Think C 5 users,

 Two problems:
 (1)
 I can't get the Application menu to appear when running my previously
 Multifinder-compatible Think-C 4 program after switching to Think-C 5 and
 System 7, either when running as a project or as a standalone application.
 Any clues?

 (2)
 What's the definitive method for creating files with icons?  Is it possible to
 prompt a user via SFPutFile and then CreateFile the file with the icon?  My
 file doesn't seem to pick up the Creator info when I do this.

 *** Please direct any replies to  [e-mail] and I will summarise
 *** if it warrants.

 Kevin Crawford
 ICRF Cell Cycle Group
 Oxford University
 UK

---------------------------

From: [e-mail] (Christian Steffen Ove Franz)
Subject: Using Fix2X and X2Fix
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH)
Date: Sun, 19 Apr 1992 16:52:24 GMT

OK, OK, I've had it!!

After RTFM tree times in *any* direction, praying to twelve different dieties
and trying everything else (except posting here) I give up.

How do you get the Fix2X and X2Fix routines to work? And yes, I *did* try
using the inline statement. No good.

I do have a workaround, but since I wasted four whole days on it it got
personal. If you have any good ideas (*any*), please email them to me.

Oh, I guess I forgot to mention, I am using THINK Pascal 4.01 (well, maybe
not for very much longer...)

Thanks alot,
Christian.

- --
- -----------------------------------------------------------------------------
Christian S. O. Franz                 |                   [e-mail]
ETH Zuerich, Swizerland               |                     [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Gerry Allwein)
Date: 20 Apr 92 11:10:03 GMT
Organization: Indiana University

That's funny, I've had troubles with X2Fix also. When our app calls it,
it causes a segment fault and then the heap gets screwed up after the new
segment is loaded. We were using MacApp 2.0 when I observed it happening.
I found that if I put the following line in my app startup (i.e., it had to
go before the InitUMacApp)

        bozo := X2Fix( 1.0 );
        InitUMacApp(12);

the problem went away. Now we are using MacApp2.0.1 but I've not gone back to
recheck it. TMON is the guy who told me my heap was messed up. This was also
under system 6.0.5. Are you having similar problems? Someone at Apple claimed
to be looking at the problem awhile back, but I can't remember who and never
received an answer.

Gerry

+++++++++++++++++++++++++++

From: [e-mail] (Kevin Draz)
Date: 22 Apr 92 06:07:37 GMT
Organization: Tektronix, Inc., Wilsonville,  OR.

In article <[e-mail]> [e-mail] (Christian Steffen Ove Franz) writes:
>OK, OK, I've had it!!
>
>After RTFM tree times in *any* direction, praying to twelve different dieties
>and trying everything else (except posting here) I give up.
>
>How do you get the Fix2X and X2Fix routines to work? And yes, I *did* try
>using the inline statement. No good.

I had no problem with X2Fix, but Fix2X gave me a headache.  There's a bug in
MPW C 3.x where it does not agree with Pascal (and therefore the OS) on how
a float returns.  You get a garbage value every time.

I had to break down and write a Pascal module which took a VAR argument and
modified it to be the result of Fix2X, then calling the Pascal from C.

As for the OS trap functions themselves, they worked fine.  You could see the
correct data on the stack when they returned.
- --
- ----
[e-mail]  | For most software publishers, quality is job 1.01.
Tektronix Color Printers|                            -- MacWeek Magazine

---------------------------

From: [e-mail] (Don Gillies)
Subject: Broken Sample Screen Saver?
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Mon, 20 Apr 1992 09:36:12 GMT

I was trying to get "blanket -- a screen saver shell" to work.  This
is a piece of code written by Christopher Tate in 1991, and (I think)
came from sumex.  It puts a tail patch on system task.  The patch
checks for keyboard / mouse activity, and if it finds none for a
certain number of ticks, it creates a new grafport, makes the GrayRgn
a nullRgn, paints the port black with "PaintRect", calls
CalcVisBehind, and then there is space in the source code for the
novice to put some animation code.  I haven't put anything there.

Well, I run MaxApplZoom, and something truly weird is happening.
After the screen saver activates, there is a 3-second pause, and then
one or more portions of the screen, in the shape of icon masks, appear
at the bottom of the screen (in my background color, pink).  If you've
ever run MaxAppleZoom, you'll notice something about the finder.  When
you boot the mac with MaxAppleZoom OFF (i.e. a smaller screen), AND
you have icons that would go beyond the boundaries of the screen, then
the finder detects this and mechanically moves the icons into standard
locations, on the screen.

Well, the finder is doing this when the screen saver activates.  I
have no idea why the finder is doing this -- I imagine the trigger for
this behavior isn't exactly something Apple is anxious to document.

Does anyone know how to avoid triggering the finder's icon mover?
Shouldn't the screen saver create a whole new frontmost Window, rather
than just making a GrafPort?  Are all these calls legal within
SystemTask?  Has anyone else experienced problems with "blanket", or
does anyone else know about a more robust screen saver (w/source
code)?

Thanks,

Don Gillies - [e-mail] - University of Illinois at Urbana-Champaign


- --




+++++++++++++++++++++++++++

From: [e-mail] (Christopher Tate)
Date: 21 Apr 92 12:22:37 GMT
Organization: Penn State University

In article <[e-mail]>, [e-mail] (Don
Gillies) says:
>
>I was trying to get "blanket -- a screen saver shell" to work.  This
>is a piece of code written by Christopher Tate in 1991, and (I think)
>came from sumex.  It puts a tail patch on system task.  The patch
>checks for keyboard / mouse activity, and if it finds none for a
>certain number of ticks, it creates a new grafport, makes the GrayRgn
>a nullRgn, paints the port black with "PaintRect", calls
>CalcVisBehind, and then there is space in the source code for the
>novice to put some animation code.  I haven't put anything there.

Oy.  It looks like you got hold of a pre-release version of that screen
saver; I abandoned the trap patch approach a while back.  However, the
behavior you describe later on (with icons moving around, weird problems
with MaxApplZoom, etc.) is something that the Finder started doing under
System 7 (you *are* running System 7, right?).  I think it has something
to do with supporting the Radius Pivot.

I submitted better code for this screen saver to the UMPG editor a while
ago, but he's had enough stuff to worry about without having to pound
away on getting volume II out...  Also, since that time I've added a
Control Panel interface and cleaned up the screen saver portion (which
nowadays uses a jGNEFilter routine instead of a patch).  As a trap patch,
it was supposed to be more an example of a squeaky-clean patch than a
solid screen saver (as I recall, it was a *head* patch, i.e. it did its
own thing, and then dropped through into the original trap routine).

If I get the time, I'll try to dig out my code and make it available;
however, no promises.  I've got graduation and a wedding coming up in
the next couple of weeks/months, and things are a little disjoint at
the moment....

- -------
Christopher Tate        |  "Isn't it funny how the people who cling like
                        |   barnacles to the traditional myths are always
[e-mail]    |   complaining that the rest of us are closed-
Bitnet:  CXT105@PSUVM   |   minded?"                   -- Dr. Dave

---------------------------

From: [e-mail] (Paul E. Jacoby)
Subject: What is "Tuna Helper" INIT in my system?
Date: 20 Apr 92 13:15:28 GMT
Organization: 3M Company

In article <jy4j2z=[e-mail]> [e-mail] (Robert Hughes) writes:
>I have the same INIT in my system, which I saw after reading on CIS that
>it was inserted there by Tune-Up. However both ID=11 and ID=13 seem
>the same, and I'm wondering if since I used both Tune-up 1.1 and 1.1.1
>if it didn't put the same code in twice??

I'm not sure how this all fits together, but I just did some wandering
in the Tune-Up 1.1.1 file with Resedit.  Here's what I found:

   In the "System 7 Tuner" file, there is a 'proc' with ID=1001. The
   code in this proc _IS_ the code in 'INIT' ID=11 and ID=13 that we are
   seeing in our System files.

   There is also a 'proc' ID=1000 which apparently does the installation
   into the System file.  There is a block of ascii at the end of this
   proc which reads ".Tuna Helper". The code in the proc appears to set
   proc 1001 to INIT 13 in the System file.

   It's kind of humorous that all of this code appears to be using a
   Gestalt selector called 'bugz' :-)

Now all that we need to know is "Why?" and "What is this thing?"  I hope
the cross-post of comp.sys.mac.programmer is helpful.
- --
| Paul E. Jacoby, Consultant  | [e-mail]  CIS:70404,2507 |
| David Mitchell & Associates |--------------------------------------|
| 3M Center, Bldg 235-3F-27   | [phone]        [phone] |
| Maplewood, MN   55144-1000  |       [work]                [home]   |

+++++++++++++++++++++++++++

From: [e-mail] (John Norstad)
Organization: Northwestern University
Date: Mon, 20 Apr 1992 14:58:23 GMT

The Tuna Helper resources are installed by the System 7 TuneUp INITs.

The id=11 resource is installed by TuneUp 1.1.

The id=13 resource is installed by TuneUp 1.1.1.

TuneUp 1.1.1 should really delete the old id=11 resource, but it doesn't.

As a friend at Apple says "I'll have two servings of Tuna Helper, please."
He also says that having the two copies there shouldn't do any harm. You
can use ResEdit to delete the id=11 one if you wish.

These resources are not put there by the Installer, but rather by the INIT
the first time you reboot after installing the tuneup. The reason they are
there is to make sure that the disappearing file/folder fix is installed
even if you hold down the Shift key.

Disclaimer: All this info is second hand. I think it's correct, but you
never know.

John Norstad
Northwestern University
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Jack Brindle)
Organization: Motorola, Mobile Data Division - Seattle, WA
Date: Mon, 20 Apr 1992 17:31:23 GMT

In article <[e-mail]> [e-mail] (Paul E. Jacoby) writes:
>In article <jy4j2z=[e-mail]> [e-mail] (Robert Hughes) writes:
>>I have the same INIT in my system, which I saw after reading on CIS that
>>it was inserted there by Tune-Up. However both ID=11 and ID=13 seem
>>the same, and I'm wondering if since I used both Tune-up 1.1 and 1.1.1
>>if it didn't put the same code in twice??
>
>I'm not sure how this all fits together, but I just did some wandering
>in the Tune-Up 1.1.1 file with Resedit.  Here's what I found:
>
>   In the "System 7 Tuner" file, there is a 'proc' with ID=1001. The
>   code in this proc _IS_ the code in 'INIT' ID=11 and ID=13 that we are
>   seeing in our System files.
>
>   There is also a 'proc' ID=1000 which apparently does the installation
>   into the System file.  There is a block of ascii at the end of this
>   proc which reads ".Tuna Helper". The code in the proc appears to set
>   proc 1001 to INIT 13 in the System file.
>
>   It's kind of humorous that all of this code appears to be using a
>   Gestalt selector called 'bugz' :-)
>
>Now all that we need to know is "Why?" and "What is this thing?"  I hope
>the cross-post of comp.sys.mac.programmer is helpful.

There are some things it does that is interesting. It apparently patches the
driver open trap to reject the opening of at least some drivers when AppleTalk
is turned off. The error return is (-21), indicating a problem with a lack
of space in the unit table (actually, this code makes no sense, but this is
what I see happening). Turn on AppleTalk, and things load properly. The
specific problem I am seeing involves a Mass Micro QuickImage-24 video
frame grabber. It's INIT closes the nuBus driver that is automatically loaded,
then installs a "new" driver from the INIT file. Problem is that when the
_open is called, the Mac returns the -21 error. M.M.'s code doesn't pick up
the error, of course, so it _assumes_ everything went ok and finishes the
install (luckily it manages not to mess anything up).

It is extremely interesting to note that it blocks only some drivers. My
fax driver loads (and works) properly!

It would be _awfully_ nice to know the mechanism that tuneup adds to block
the installation of the driver.

Jack Brindle
ham radio: wa4fib
internet: [e-mail]


+++++++++++++++++++++++++++

Date: Mon, 20 Apr 92 18:59:08 MDT
From: [e-mail] (john r park)
Organization: Brigham Young University, Provo UT USA

>I have the same INIT in my system, which I saw after reading on CIS that
>it was inserted there by Tune-Up. However both ID=11 and ID=13 seem
>the same, and I'm wondering if since I used both Tune-up 1.1 and 1.1.1
>if it didn't put the same code in twice??

I have Tuneup 1.1.1 installed and I don't have any such TUNA INIT in my
system folder, extension folder, or control panels folder.  Why am I
missing it if it's supposed to be there?

- --
**************************************************************
*  John R Park           |     Dept of Mech. Engineering     *
*  [e-mail]     |     Brigham Young University      *
**************************************************************

+++++++++++++++++++++++++++

From: [e-mail] (John Nagle)
Date: 21 Apr 92 03:00:57 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)


      It's worth noting that secretly installing hidden programs as
a byproduct of something else comes very close to virus-like behavior.
If they cause harm, one might have cause to bring computer crime charges.
Check out the Federal computer crime statutes.

                    John Nagle

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Date: 21 Apr 92 18:02:55 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> [e-mail] (John Nagle) writes:
>      It's worth noting that secretly installing hidden programs as
>a byproduct of something else comes very close to virus-like behavior.
>If they cause harm, one might have cause to bring computer crime charges.
>Check out the Federal computer crime statutes.

Oh puh-LEEZE!  All that's happening with the Tuneup is that an OS patch is
being installed from a file other than the System file.  There's lots and
lots of patch code that gets installed before any extensions are loaded, and
you can't disable that process with a key combination.  Should Apple be
prosecuted for that, too?  Yes, Tuneup has to do some skanky stuff to allow
for patches that are in separate files.  This is a price to be paid for
adding this sort of functionality without forcing a new operating system
release.  I think it is very likely that System 7.1 will have a different
method of installing patch code that "knows about" Tuneup-like files.  In the
meantime, chill.

- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s++ e+ h- pv     |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Thomas Aaron Insel)
Date: 21 Apr 92 19:32:19 GMT
Organization: {not speaking for the} University of Illinois at Urbana

[e-mail] (John Nagle) writes:

>       It's worth noting that secretly installing hidden programs as
> a byproduct of something else comes very close to virus-like behavior.
> If they cause harm, one might have cause to bring computer crime charges.
> Check out the Federal computer crime statutes.

Oh come on, Tuna Helper is installed by Tuneup in the system file to insure
that certain bug-fixes remain in effect even when the user boots with
extensions turned off.  This is completely legitimate--when you install
system software, the system gets changed. It's that simple.
- --
Thomas Aaron Insel ([e-mail])
  I speak for myself, and not for the State or University of Illinois.
  "We must not confuse dissent with disloyalty." -- Edward R. Murrow

+++++++++++++++++++++++++++

From: [e-mail] (Matthew T. Russotto)
Date: Wed, 22 Apr 92 01:41:11 GMT
Organization: College of Engineering, University of Maryland, College Park

In article <[e-mail]> [e-mail] (John Nagle) writes:
>
>      It's worth noting that secretly installing hidden programs as
>a byproduct of something else comes very close to virus-like behavior.
>If they cause harm, one might have cause to bring computer crime charges.
>Check out the Federal computer crime statutes.

And people thought I was paranoid when I starting pointing out
possible abuses of these laws.



- --
Matthew T. Russotto    [e-mail]    [e-mail]
Some news readers expect "Disclaimer:" here.
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)

---------------------------

From: [e-mail] (Stephen Uitti)
Subject: MPW's C preprocessor bug
Organization: Interactive Systems, Cambridge, MA 02138-5302
Date: Mon, 20 Apr 1992 22:15:15 GMT

I'm doing cross platform development in C++ with Windows people.
I came accross the following:

#ifdef macintosh    // comment
...
#endif

It seems that "//" end of line comments can't be attached to
C preprocessor statements if the statement resolves to TRUE.

I get "syntax error".  It took a longer time that I'd like to admit
to figure out what changes caused this error.  Really.  Is there
any excuse for non-descriptive error messages?  How about:
    Illegal token '//', expecting statement.
Almost anything would help.

Stephen.
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Alan J Rosenthal)
Date: 21 Apr 92 14:24:30 GMT
Organization: Dynamic Graphics Project, University of Toronto

[e-mail] (Stephen Uitti) writes:
>#ifdef macintosh    // comment
>...
>#endif
>
>It seems that "//" end of line comments can't be attached to
>C preprocessor statements if the statement resolves to TRUE.

Actually, you can't use them on any preprocessor statements at all, EXCEPT that
if you have something like #endif it just ignores the rest of the line so you
can put whatever crap there you want.  I'd recommend simply using the /* */
comments on all preprocessor lines.

---------------------------

From: [e-mail] (Jeffrey T. Hutzelman)
Subject: LaserPrep enforcer ??
Date: 21 Apr 92 00:37:50 GMT
Organization: Sophomore, Electrical and Computer Engineering, Carnegie Mellon, Pittsburgh, PA

On 18-Mar-92 in C.S.M.P. Digest V1 #54
user [e-mail] writes:
>>I'm looking for some PostScript code that will stop a LaserWriter from
>>rebooting if someone trys to print using a LaserPrep other than a system
>>7 one.
>>
>>Does anyone have one of these ?
>>
>
>The code to restart a LaserWriter (or other PS device) is:
>
>systemdict begin quit
>
>In level-2, this is a protected command, so
>
>serverdict begin 0 exitserver
>systemdict begin quit
>
>I don't know which version LaserWriters <= 6 use, and it can make a
>difference.  It's pretty hard to do a patch which would negate this code,
>and impossible to do pretty.
>
>You could try replacing exitserver's definition so that it's a no-op, which
>will probably fail pre-7.0 LaserWriters jobs when they go to download their
>prep.  I haven't tried it, but here it would be:
>
>%!PS-Adobe
>serverdict begin 0 exitserver
>userdict /exitserver { pop } bind put
>%%End-of-File
>
>which makes exitserver eat it's argument, and continue on.  Or you could go
>one further and replace pop with { stop } which will force an error in most
>all cases, dumping the job.
>
>This is likely to have ramifications (pronounced "bugs") with something out
>there.
>

OK, I know this is a little old; I'm reading month-old digests...

If quit is a protected command (which it should be), then it is
NECESSARY to execute exitserver for it to have any effect.  The result
is that the printer
can be protected by causing it to execute

serverdict begin 0 exitserver
statusdict begin 0 42 setpassword
end

This will set the password to "42".  Now, rebooting the printer requires
sending it

serverdict begin 42 exitserver
systemdict begin quit

Of course, the 42 can be replaced by any number you want.  To change it to 43,
execute

serverdict begin 42 exitserver
statusdict begin 42 43 setpassword
end

Or you can restore it to zero in the same way.

Password-protecting a printer in this manner prevents changing any of
the configuration settings, including the printer's name.  All of the
public cluster
printers at CMU (where the original poster is from) are protected in this way.
This protection does NOT go away if you turn off or unplug the printer.  If
you forget the password, you can get it reset at by your friendly neighborhood
authorized Apple service center, but they will probably charge you, and it will
probably result in losing all the other configuration settings as well.

- -- Jeffrey Hutzelman

[e-mail], [e-mail], or JeffreyH11 on America Online

+++++++++++++++++++++++++++

From: [e-mail] (Kevin Draz)
Date: 22 Apr 92 06:53:42 GMT
Organization: Tektronix, Inc., Wilsonville,  OR.

In article <[e-mail]> [e-mail] (Jeffrey T. Hutzelman) writes:

[original content of thread deleted, regarding changing exitserver password
on a PS printer to avoid "prep wars"]

Whilst sitting late nite, writing my original posting, I originally included
the possibility of changing the NV exitserver password.  After rereading my
message before posting it, I decided NOT to mention the password change,
precisely for the reasons you list.  If you lose nonzero password, you could
be in for a rough, or expensive time [or both].  And what if you're not a
site administrator, and you change the password?  What does the _real_
administrator do?  [Of course, anyone with a moderate knowledge of PS could
change a zero password to anything desired if they have sufficient penchant
for software vandalism]

I decided that it would be irresponsible to tell someone how to do something
potentially undoable [or difficult to undo], and I modified my post.

Please don't take this wrong - it's not really a criticism of your
suggestion, just my own personal paranoias.  I'm sure in most cases,
changing the password is the most obvious and effective thing to do.

BTW: There was once rumor of a virus [which I have never seen, and therefore
may not exist] which would change the exitserver password of a PS printer to
something random, thereby causing untold grief trying to reset it.  To
address this, Apple released a simple little application [which I have, and
therefore know for a fact to exist] which uses the non-protected machine
language escape operator "cexec" to reset the NV password to zero.  This
only works on "true" Adobe 68K based PS printers.

Other PS vendors have addressed this issue in different ways.  Our older PS
clone interpreter has a secret value for exitserver which always is accepted
and resets the password to zero.  Phoenix's clone simply does not store the
password in NV memory.  It's always zero at powerup/reset.  Our Adobe
level-2 machines have a secret switch combo to blast everything in NV memory
except the copy-count.

Let's take this thread to comp.lang.postscript, if anyone feels inclined to
reply.

- --
- ----
[e-mail]  | For most software publishers, quality is job 1.01.
Tektronix Color Printers|                            -- MacWeek Magazine

---------------------------

From: [e-mail] (Louis Slothouber)
Subject: Finding the Event Queue, etc.
Date: 21 Apr 92 19:45:16 GMT
Organization: University of Houston

I have a couple of questions regarding the location of Event information
and low memory globals for individual processes Under System 7:

(1) Is there an easy way to find the header of the event queue for another
process? (i.e. a process other than the currently executing application)

(2) Where is the state information (i.e., A5, low-mem globals, etc) info.
stored for inactive processes? Might there be undocumented fields in
Process Manager records that contain this info? If so, where are they?

Thanks!

+++++++++++++++++++++++++++

From: [e-mail] (Pete Gontier)
Date: 22 Apr 92 04:43:08 GMT

In <[e-mail]> [e-mail] (Louis Slothouber) writes:

>(1) Is there an easy way to find the header of the event queue for another
>process? (i.e. a process other than the currently executing application)

There is only one event queue for all applications. Hence Phil Shapiro's
recent suggestion here that TCL should not be walking the event queue
looking for command-period because some hapless TCL user might call it
in the background and find a command-period that should have gone to
some app in the foreground.
- --
 Pete Gontier // EC Technology // [e-mail]

---------------------------

Subject: Alternatives to fopen() in Think C?
From: Alan R. Heyd <[e-mail]>
Date: Wednesday, 22 Apr 1992 00:38:51 EDT
Organization: Penn State University

What is the best way to open a file using Think C 5.0.  My problem is that
fopen() must by-pass the Finder because under Sys-7.0 if I use fopen() to
open an alias it opens the alias and not the file it points to.  Note the file
name is read from another file so I don't need the Standard File Package
which uses the Open File dialog window.

Any help on this problem would be appreciated.  I have access to Inside
Mac v. 1--6 so even a page number in Inside Mac would help.

Thanks

Alan Heyd
[e-mail]

---------------------------

From: [e-mail] (R. Glenn Stauffer)
Subject: Apple Installer Scripts
Date: 14 Apr 92 18:17:26 GMT
Organization: Swarthmore College Computing Center

I am trying to patch the installer script that came with WordPerfect to
facilitate
installation of the software from a network drive.

Can someone give me a clue as to how I can go about editing the included
script or creating my
own?

R. Glenn Stauffer
Micro-Computer Specialist, Swarthmore College Computing Center
Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Operator)
Organization: Wilder Systems, Trik Product Group
Date: Thu, 16 Apr 1992 14:21:50 GMT

In article <[e-mail]> [e-mail] (R. Glenn Stauffer) writes:
>I am trying to patch the installer script that came with WordPerfect to
>facilitate
>installation of the software from a network drive.
>
>Can someone give me a clue as to how I can go about editing the included
>script or creating my
>own?
>
>R. Glenn Stauffer
>Micro-Computer Specialist, Swarthmore College Computing Center
>Internet: [e-mail]

Instead of trying to understand the cryptic twistings of the Apple
Installer, you might want to give NetDistributor a try. Several
major universities and companies use it to do exactly what you're
trying to do while avoiding the hassle of learning how to write
installer scripts.

Basically, NetDistributor lets you create packages which, when
double-clicked, install files into the correct places on an
end-user's machine. It's kind of like a smart, self-expanding
archive. And, it's MUCH easier to put together than the Installer.

If you'd like to know more about NetDistributor (esp. our new
2.0 version), send email to [e-mail].

Throop

---------------------------

From: [e-mail] (Benjamin T Sander)
Subject: Too many files open?
Date: 14 Apr 92 18:52:31 GMT
Organization: University of Illinois at Urbana

Anybody know what could cause an error -42, too many files open?
Specifically, what expendable resource does my mac exhaust when
it opens a file?  Where can I get more?

(The error occurs after several calls to _OpenResFile on various
resource files which are all located on an Appleshare volume. I don't
know if this is relevant or not.)

Thanks in advance!

Ben Sander
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Steve Day)
Date: 15 Apr 92 04:16:12 GMT
Organization: Washington State University, Vancouver Campus

In article <[e-mail]> [e-mail] (Benjamin T Sander) writes:
>Anybody know what could cause an error -42, too many files open?
>Specifically, what expendable resource does my mac exhaust when
>it opens a file?  Where can I get more?
>
>(The error occurs after several calls to _OpenResFile on various
>resource files which are all located on an Appleshare volume. I don't
>know if this is relevant or not.)
>
On startup the system allocates a (limited, fixed) number of FCBs (File
Control Blocks).  The number to be allocated is stored in the boot blocks
of the startup drive and once they are set up the system can't create more
as they are needed :-(  These blocks are also shared among all programs
including the system and finder and an application also counts as a file.
I'm not sure if opening a resource fork and a data fork on the same file is
considered one or two files (Anyone have an answer to that?).

- --

Steve Day
N7VHY

+++++++++++++++++++++++++++

From: [e-mail] (Matthew T. Russotto)
Date: Wed, 15 Apr 92 14:49:46 GMT
Organization: College of Engineering, University of Maryland, College Park

In article <[e-mail]> [e-mail] (Steve Day) writes:
>>
>On startup the system allocates a (limited, fixed) number of FCBs (File
>Control Blocks).  The number to be allocated is stored in the boot blocks
>of the startup drive and once they are set up the system can't create more
>as they are needed :-(  These blocks are also shared among all programs
>including the system and finder and an application also counts as a file.
>I'm not sure if opening a resource fork and a data fork on the same file is
>considered one or two files (Anyone have an answer to that?).

Yes, they are considered two files.  System 7, and System 6 using an
extension called "Up your FCBs" allocate FCBs as needed, solving this
problem.


- --
Matthew T. Russotto    [e-mail]    [e-mail]
Some news readers expect "Disclaimer:" here.
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)

+++++++++++++++++++++++++++

From: [e-mail] (Phil Shapiro)
Organization: Symantec Corp.
Date: Wed, 15 Apr 1992 22:10:23 GMT

In article <[e-mail]> [e-mail] (Steve Day) writes:

   On startup the system allocates a (limited, fixed) number of FCBs
   (File Control Blocks).  The number to be allocated is stored in the
   boot blocks of the startup drive and once they are set up the
   system can't create more as they are needed :-( These blocks are
   also shared among all programs including the system and finder and
   an application also counts as a file.  I'm not sure if opening a
   resource fork and a data fork on the same file is considered one or
   two files (Anyone have an answer to that?).

It's two files. You can check this by using the "file" dcmd in
MacsBug.

I had heard that in System 7, the FCB queue is dynamically resizable,
and is no longer limited to the length in the boot blocks. I didn't
see any docs about this in IM VI, however...

    -phil
- --
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Organization: The World Public Access UNIX, Brookline, MA
Date: Fri, 17 Apr 1992 14:33:26 GMT

This may have been answered but opening a data fork is ONE file and
opening a resource fork is ONE file. therefore...opening both forks
of a single "file" really counts as TWO files :)













- --
- -- joe zobkiw                           [e-mail]
- -- mac.synthesis.MIDI.development.THINK C.asm.communications
- -- digital audio.cdrom.mountain bikes.black cars.perrier.H20

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 17 Apr 92 22:09:52 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail]
(Steve Day) writes:
> In article <[e-mail]> [e-mail]
(Benjamin T Sander) writes:
> >Anybody know what could cause an error -42, too many files open?
> >Specifically, what expendable resource does my mac exhaust when
> >it opens a file?  Where can I get more?
> >
> >(The error occurs after several calls to _OpenResFile on various
> >resource files which are all located on an Appleshare volume. I don't
> >know if this is relevant or not.)
> >
> On startup the system allocates a (limited, fixed) number of FCBs (File
> Control Blocks).  The number to be allocated is stored in the boot blocks
> of the startup drive and once they are set up the system can't create more
> as they are needed :-(  These blocks are also shared among all programs
> including the system and finder and an application also counts as a file.
> I'm not sure if opening a resource fork and a data fork on the same file is
> considered one or two files (Anyone have an answer to that?).

The amount of FCB blocks is dynamically allocated in System 7 - yet another
reason to upgrade to this level.

Cheers,
Kent Sandvik

+++++++++++++++++++++++++++

From: [e-mail] (Jim Cathey)
Date: 20 Apr 92 20:25:31 GMT
Organization: ISC-Bunker Ramo, An Olivetti Company

In article <[e-mail]> [e-mail] (Phil Shapiro) writes:
>   On startup the system allocates a (limited, fixed) number of FCBs
>   (File Control Blocks).  The number to be allocated is stored in the...

>I had heard that in System 7, the FCB queue is dynamically resizable,
>and is no longer limited to the length in the boot blocks. I didn't
>see any docs about this in IM VI, however...

And, the downside is that you can no longer do a PBOpen(pb, ASYNC)
which worked before.  This is because of the need to allocate memory to
dynamically extend the table.  Yet another nice feature of the Mac OS
gets lost.  (Not that you could actually ever do it because the damned
SCSI driver doesn't do ASYNC either).  Being nibbled to death by
ducks...

+----------------+
! II      CCCCCC !  Jim Cathey
! II  SSSSCC     !  ISC-Bunker Ramo
! II      CC     !  TAF-C8;  Spokane, WA  99220
! IISSSS  CC     !  UUCP: uunet!isc-br!jimc ([e-mail])
! II      CCCCCC !  [phone]
+----------------+
            "PC's --- the junk bonds of the computer industry"

+++++++++++++++++++++++++++

From: [e-mail] (Matthew T. Russotto)
Date: Mon, 20 Apr 92 21:42:37 GMT
Organization: College of Engineering, University of Maryland, College Park

In article <[e-mail]> [e-mail] (Jim Cathey) writes:
>
>And, the downside is that you can no longer do a PBOpen(pb, ASYNC)
>which worked before.  This is because of the need to allocate memory to
>dynamically extend the table.  Yet another nice feature of the Mac OS
>gets lost.  (Not that you could actually ever do it because the damned
>SCSI driver doesn't do ASYNC either).  Being nibbled to death by
>ducks...

Agreed about the SCSI driver, but removing PBOpen(pb, Async) isn't
a necessary consequence of dynamically resizable boot blocks.  Seems
to me that all PBOpen would need to do is fail (too many files open)
if called async.


- --
Matthew T. Russotto    [e-mail]    [e-mail]
Some news readers expect "Disclaimer:" here.
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)

+++++++++++++++++++++++++++

From: [e-mail] (Quinn "The Eskimo!")
Organization: The University of Western Australia
Date: Tue, 21 Apr 1992 02:08:17 GMT

In article <[e-mail]>, [e-mail] (Jim Cathey) writes:
>
> In article <[e-mail]> [e-mail] (Phil Shapiro) writes:
> >   On startup the system allocates a (limited, fixed) number of FCBs
> >   (File Control Blocks).  The number to be allocated is stored in the...
>
> >I had heard that in System 7, the FCB queue is dynamically resizable,
> >and is no longer limited to the length in the boot blocks. I didn't
> >see any docs about this in IM VI, however...

Neither did I but it was documented somewhere, perhaps in one of the beta
release notes.  I remember seeing it but I can't remember where )-:

> And, the downside is that you can no longer do a PBOpen(pb, ASYNC)
> which worked before.  This is because of the need to allocate memory to
> dynamically extend the table.  Yet another nice feature of the Mac OS
> gets lost.

I hate to tell you this but you never could.  IM III-212 clearly marks
PBOpen as one of those "routines that may move or purge memory".  That's
why the toolbox people decided that it would be OK to change it so that it
actually did move memory.

> Being nibbled to death by ducks...

But does it have wings?  And does it float?  And is it as big as a church?

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia
  -- Who wouldn't rely on PBOpen not moving memory anyway.


+++++++++++++++++++++++++++

From: [e-mail] (Jim Cathey)
Date: 21 Apr 92 20:26:05 GMT
Organization: ISC-Bunker Ramo, An Olivetti Company

In article <[e-mail]> [e-mail] (Quinn "The Eskimo!") writes:
>> And, the downside is that you can no longer do a PBOpen(pb, ASYNC)...

>I hate to tell you this but you never could.  IM III-212 clearly marks
>PBOpen as one of those "routines that may move or purge memory".  That's
>why the toolbox people decided that it would be OK to change it so that it
>actually did move memory.

I misspoke, as it turns out.  You _should_ be able to do an ASYNC open
from the foreground code, whether or not it meddles with memory (this
would probably mean it wasn't truly asynchronous, though [unless it
could arrange to do all its memory mangling before it scheduled all the
asynchronous device I/O and returned to foreground code, which it can't
'cause that's not how the Device Manager works]), but you would not be
able to in turn do one in the completion routine of another
asynchronous request.  A different kettle of ducks, entirely.  (But
related).  I just hate to see asynchronicity (the heart and soul of
a truly responsive event-driven system) being eaten away.

>> Being nibbled to death by ducks...
>
>But does it have wings?  And does it float?  And is it as big as a church?

... A witch!  A witch!

+----------------+
! II      CCCCCC !  Jim Cathey
! II  SSSSCC     !  ISC-Bunker Ramo
! II      CC     !  TAF-C8;  Spokane, WA  99220
! IISSSS  CC     !  UUCP: uunet!isc-br!jimc ([e-mail])
! II      CCCCCC !  [phone]
+----------------+
            "PC's --- the junk bonds of the computer industry"

---------------------------

End of C.S.M.P. Digest
**********************